昨天你做了一件很多主管不敢做的事：告訴 CEO「我們不能同時做十件事」。
你導入了 WIP Limit，規定每個人手上「真正進行」的任務不能超過三個，超過的，必須先停下來、排隊。
會議室裡一片沉默。有人終於敢說「我做不完」，有人鬆了一口氣，不用再假裝「我可以」。
但當你回到座位、打開專案清單時，你發現了一個更殘酷的現實：
你限制了個人的 WIP，但組織層級的 WIP 依然爆表。
三個團隊同時踩著 15 個專案：
每個都說「很重要」，每個都有 Stakeholder 在盯，每個都在「持續推進中」。
但真相是：每個專案都只分配到 10–20% 的注意力。
結果就是：什麼都在做，什麼都做不完。
限制 WIP 只是第一步。真正需要勇氣的，是下一步：
凍結一批專案，把火力集中在少數關鍵目標上。
週一的專案 Review 會議上，你要求每個團隊報告「進度」。
Data Team Lead：「GPSS 對接 65%，Feature Store 40%，監控工具 55%，OSV 分類 30%……」
Platform Team Lead：「MLOps 重構 70%，容器化 50%，CI/CD 加速 45%……」
AI Team Lead：「RAG 提升 80%，多模態實驗 25%，Agent 評估 60%……」
15 個專案，每個都在 25–80% 之間。
過去三個月，完成並上線的專案數：0。
你問：「如果只能完成一個，你會選哪個？」
沉默。
Data Lead：「GPSS 對接吧……但監控也很急……」
Platform Lead：「MLOps 重構優先，會加速所有專案……但 CI/CD 也卡很多人……」
AI Lead：「RAG 已經 80% 了，應該做完……但多模態不早點開始，三個月後會來不及……」
你突然看清楚了。
每個人都知道該做什麼，但沒有人敢說「其他先不做」。
因為那意味著要跟某些 Stakeholder 說「你的專案先停」。
而這，需要的不是技術能力，是政治勇氣。
你打開試算表，把 15 個專案列出來，標上「商業價值、技術風險、資源需求、完成度」。
然後你意識到自己站在一個岔路口：
| 🔴 選項 A：重新排序，但所有專案都保留 | 🔵 選項 B：凍結一批，把火力集中在 3-5 個關鍵專案 |
|---|---|
| 短期效益：✓ 沒有人被得罪，大家覺得「至少還在列表上」長期代價：✗ 資源依然被稀釋，只是稀釋的「順序」改變✗ 三個月後依然沒有任何一個專案能真正做完結果：✗ 淪為排序的假象，實際上什麼都沒改變 | 短期代價：✗ 被凍結的專案 Owner 會不爽✗ 面對「為什麼是我」、「這明明很重要」等阻力長期效益：✓ 關鍵專案獲得充足資源，能在 2 個月內順利上線✓ 形成「完成 -> 解凍 -> 再完成」的健康良性循環結果：✓ 短期面對政治壓力，長期交付速度翻倍 |
如果是你，CEO 下週要看進度，15 個專案的 Stakeholder 都在等，你敢不敢說「我要凍結 10 個」？
認真想三十秒。
你會選 A 還是 B？
為什麼？
正確答案是 B。
但這是最需要勇氣的選擇。因為「凍結」聽起來像是「放棄」，而沒有人想當那個「殺掉專案的壞人」。
但真相是：資源有限，「都要」等於「不要」。
《鳳凰專案》裡 Erik 說：「工廠產能固定。產線上越多半成品，每一件完成越慢。」
這就是 Little's Law（利特爾法則）：
Lead Time = WIP*Throughput
你的團隊產能為「每個月完成 2 個專案」。同時推行 10 個，每個需要花費 5 個月；而若只推行 4 個，則每個只需 2 個月便能完成。
同時做的事越多，每件事前進的速度就越慢。這是鐵一般的數學定律。
更殘酷的是隱形成本：
團隊每個人都很忙，卻沒有一個專案能完成。
《鳳凰專案》給的解法很清楚：
Stop Starting, Start Finishing.
停止開始新的，專心完成已有的。
凍結不是放棄，是排隊。
你不是說「這個專案不做了」，你是說「這個專案排在第 11 順位，等前面 5 個完成後再行解凍」。
把稀缺的火力集中在極少數目標上，做完一批、解凍下一批，形成「完成 -> 解凍 -> 再完成」的良性循環。
少即是多。專注即是速度。
問題是，「凍結哪些」本身就是一場政治鬥爭。
每個 Stakeholder 都會堅稱「我的專案最重要」，你很難單憑「直覺」來說服所有人。
這時候，AI Agent 可以幫你做一件事：把專案價值、成本、風險量化成數據，產出一個「該凍結誰」的客觀排序。
graph TD
A[15 個專案清單] --> B[Agent 分析]
B --> C{量化指標}
C --> D[商業價值<br/>影響營收/客戶數/策略目標]
C --> E[技術風險<br/>依賴複雜度/技術債/失敗機率]
C --> F[資源需求<br/>人力/時間/外部依賴]
C --> G[完成度<br/>目前進度/沉沒成本]
D --> H[計算綜合分數]
E --> H
F --> H
G --> H
H --> I[排序建議:<br/>保留 Top 5,凍結其餘 10]
I --> J[產出報告:<br/>為何選這 5 個優先]
J --> K[給主管一個「有數據支撐」<br/>的取捨方案]
Agent 做的事很直接：
更重要的是，Agent 產出的不只是排序，還有完整的量化依據：
這就是 2026 年的做法：不是主管憑感覺拍板，而是讓 Agent 從數據裡算出「客觀上該做什麼」，再由主管決斷。
當你拿著這份報告走進會議室，對話就從「為什麼是我被砍」，變成「數據顯示這樣排序最優，你有不同意見嗎？」
取捨從政治博弈，變成數據討論。
來看一個常見的情況（綜合改編，數字示意）。
想像一個 18 人的 AI 平台團隊，踩著 15 個並行專案，連續三季「進度正常」但沒有一個上線。
新來的技術總監受不了了，召開全員會議，在白板上畫出 15 個專案，讓大家投票：「如果只能留 3 個，留哪 3 個？」
投票結果驚人地一致：GPSS 對接、RAG 優化、MLOps 重構。
他當場宣布：「其他 12 個，全部凍結。不是取消，是排隊。這 3 個做完上線後，我們再解凍下一批。」
會議室一片嘩然。有人質疑「業務會罵」，有人擔心「技術債會累積」，有人不爽「我的專案被砍」。
他說：「我知道這很痛。但現況是：我們同時做 15 件事，結果一件都做不完。與其繼續這樣，不如賭一把——集中火力，看看會怎樣。」
兩個月後：
團隊士氣從「疲憊應付」變成「看見成果」。
接下來，他們解凍了 3 個專案，再次集中火力，再次兩個月全部上線。
一年內，15 個專案完成 12 個。
對比過去一年：15 個專案完成 0 個。
事後回顧，那位技術總監說：「凍結專案的那場會議，是我當主管以來壓力最大的一次。但如果我當時沒那個勇氣，這個團隊現在還在原地打轉。」
排序與取捨，是管理者最不技術、卻最關鍵的能力。
「什麼都想要留，最後什麼都留不住。勇氣不是什麼都做，而是敢說『這個先不做』。」
如果只能留三個專案，你留哪三個？
其他為什麼還在跑？
如果你答不出來，或是答案是「都很重要，無法取捨」，那你就知道為什麼你的團隊一直在忙、卻什麼都交付不了。
明天，我們會進入 The Second Way 的領域：回饋循環。
你讓團隊聚焦了、流動起來了，但如果問題總是「出事了才知道」，你永遠在救火而不是預防。
你需要讓機器每天告訴你哪裡壞了，而不是等客戶來罵……
Day 16 見。
iThome鐵人賽
看影片追技術